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ABSTRACT 


Fascinated with robotics open source integrated components MARIE [1], 
ROS [2] PLAYER/STAGE [3] and CARMEN [4] are available in the field of 
robotics application. We aim at developing an asynchronous concurrent robotics 
application based on subsumption [5] architecture using PLAY ER/STAGE and already 
freely available services on the internet. We used wanderer and wall follower services 
embedded inside an actor [6] [7] and integrated these services to two different robots of 


Keywords: ens í l ; 
same configurations in our promise based framework that provides actor as a service. 
Actor The two robots switch their services based on color detected (red,green,blue) during 
Concurrency their movement in an environment asynchronously. Using actor as a service fills 
Promise the gap of SOA [8] & EDA [9] by providing synchronous and asynchronous 
Petrinet support for communication. We measured the performance of time taken in completion 
Player of services in promise [10] based implementation, synchronous and asynchronous 
Stage callback [11] based implementation. We developed a model to prove deadlock 
l freeness in our integrated architecture using petrinet [12] interface composition. We 
Subsumption Sais l l 
have also been able to justify that component integrated on promise based framework 
takes less time in service completion than synchronous and asynchronous callback 
based services. 
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1. INTRODUCTION 

For the evaluation of the field, it is required to integrate available services so that complex systems 
can be built upon these available services without wasting time in code replications. Components are built 
independently following an own set of protocols and communications strategies, integrating these together 
is not a trivial task. This is also favored because services that are well tested and debugged can be reused. 
Proposed Architecture is implemented using principles of Service Oriented Architecture(SOA) & Event Driven 
Architecture(EDA). We have used Service Oriented Actors which fulfill the gap of SOA and EDA by exposing 
services as actors and providing asynchronous communication. Here an actor containing a list of robotic 
services are exposed and used for communication by another client actors. Actor & Promise is used to facilitate 
asynchronous concurrent communication using promise and maintains the state of messages using actors. We 
have developed an extension of actor model discussed in [13] and provided an abstraction of promises to accept 
and deliver concurrent request and response. The service oriented actor provides services which have return 
type either void or promise. Two actors communicate with each other by implicit message passing. None of 
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the other actor-based framework for Java developed earlier supports promises and implicit message passing 
mechanism as they are developed on an older version of Java 8.0. 

While developing the application we have kept in mind that integrated services should be cost efficient 
and easy. Moreover, architecture should be flexible enough to integrate modified and new service without 
obsoleting or rebuilding the architecture [14]. Such integration should not be too complex. Integrating new 
service to architecture should not involve rebuilding whole architecture again thus service can be connected on 
the fly to the architecture. 

If service is on the host computer, it is being invoked from the same host and if not, service is 
requested from the host having that service. In case, if a service is not present then system should 
terminate gracefully with proper error messages so that user can diagnose the problem with the application 
created. SOA based architectural concept uses description language to define the function and services of 
the component interfaces to be discovered over the network. SOA facilitates isolation practice of software 
development. Earlier SILO [15] based approach had been inefficient where same functionalities were being 
developed, deployed and maintained multiple times by other organizations refer to Figure | and 2. 
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Figure 2. Request/Reply Mechanism in SOA 


Gartner, in 2003 proposed a new design paradigm based on events using publisher/subscriber pattern 
as event-driven architecture(EDA). EDA is not a replacement of SOA but complements SOA by asynchronous 
message communication than request/reply used in SOA. 

Every actor writes their messages to other actor’s mailbox for sending their request to be processed. 
The response sent by another actor is written back to callback queue of the actors. Every actor reads its mailbox 
queue after reading the messages of its callback queue. Finally, each actor is copied to global actor space of 
a single thread. Thus works as a single threaded model and each actor may work as publisher and subscriber. 
We are using our actor-based framework as shown in Figure 3, it uses different actors with their mailbox and 
callback queue. 
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Figure 3. Request/Reply in actor-based framework 


This paper is organized as followed: section II introduces the implementation architecture, 
section III models services and discuss the challenges and implementation details of subsumption architecture. 
Section IV discuss the performance evaluation of services on synchronous vs. asynchronous using callback vs. 
asynchronous using promises, section V deals with verification of deadlock in the composed system using Petri 
net model and finally section VI introduces conclusion and future work. 


2. IMPLEMENTATION ARCHITECTURE 


Our architecture integrates loosely coupled components based on Service Oriented Actors. 
An application needs to be developed using the functionalities provided by different components. A single 
component may provide more than one functionality which may or may not interrelated, such as audio and 
video processing or collision avoidance and path planning. Further, it’s possible that these packages are not 
present on the same machine hence creating a distributed environment. At the highest level of abstraction, 


the proposed architecture will look as illustrated in Figure 4. 





Application 


Figure 4. High level abstraction of Application 
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Proposed architecture can be understood from the following two perspectives: 
A. Abstraction Layers 
B. Component Framework 


2.1. Abstraction Layers 


To provide multiple levels of abstraction three layers are defined in proposed architecture [16]. Each 
layer provides the certain set of functions to the layer above it. The three layers are illustrated in Figure 5. 


APPLICATION LAYER 


COMMUNICATION LAYER 


SERVICE LAYER 





Figure 5. Different Layers of Architecture 


2.1.1. Service Layer 

It is the lowest layer where the services reside. This layer is also the core layer having all 
the functionalities required by the application need to be developed. Each service is nothing but 
functionality that a component provides [17]. All the components integrated are an integral part of 
the Service Layer. These components may provide much functionality. These packages may be heterogeneous, 
built in different programming languages, using different communication protocols and may present on 
different machines. Hence in SOA’s terminology Service layer is a collection of Service Providers. 


2.1.2. Communication Layer 


This layer is present above Service layer and responsible for all types of communication between 
the services and application. This layer defines the communication mechanism, strategies, and protocol. 
The communication mechanisms used are publish/subscribe and request/reply [18]. 


2.1.3. Application Layer 


This layer sits right above Communication Layer. The user interacts with this layer. It provides 
functions like service discovery, service invocation and synchronization between services. 


2.2. Component Framework 


Proposed architecture composed of different building blocks. These blocks are services, interfaces, 
bus, broker and application. These building blocks are defined below in Figure 6, which shows component 
together with the interface internal working. 


2.2.1. Service 


Each of the robotics components can be treated as the service. The application requires these services 
to perform the designated task. A service may provide many functionalities like navigation and path planning. 


Int J Rob & Autom, Vol. 8, No. 4, December 2019 : 217 — 244 


Int J Rob & Autom ISSN: 2089-4856 g 221 


Component Composed of 
Different functionalities 


t 






Control Flow 
Line 


Data Flow Line 





Figure 6. Interface 


2.2.2. Interfaces 

The interface is component specific that makes component compatible with architecture. Such an 
interface can be considered as middleware between architecture and component. All the communications 
between component and architecture occur through the interface only. All the components need to be 
connected, they must have an interface. If a new component needs to be connected then an interface is required 
according to requirement of that component. Developing an interface requires the deep study of a component 
to be connected for the insight knowledge of communication protocols, data formats, and robotics standards. 
Interface has different units as listed below: 


2.2.2.1. Component Communication Unit (CCU) 

This unit communicates with the component, more precisely with the service in which an application 
is interested. CCU supports both control signal and the data signal. Control signals are responsible for invoking 
and termination of required service. Data signals are for the transfer of service specific data. 


2.2.2.2. Data Conversion Unit (DCU) 

Robotics packages are data specific. They require the data in particular format and type. This unit is 
responsible for converting data from application-specific data to service specific data and vice versa. This data 
is read and written to the buffer built inside DCU for providing latency. 


2.2.2.3. Bus Communication Unit (BCU) 
It is responsible for communication between interface and bus and vice versa. 


2.2.3. Bus 

The bus is a messaging infrastructure to allow different systems to communicate through shared set of 
interfaces. This is analogous to bus in a computer system which serves as the focal point for communication 
between CPU, Main memory, and peripherals. Messages may be data messages or control messages. Control 
messages enable managing services while data messages are service specific data that is input and output 
data of services. 


2.2.4. Broker 

It synchronizes different services. The duty of the broker/arbitrator is to discover services required 
for the application to work. For this record of services are maintained for rapid service discovery. This also 
involves invoking the service in case service is not running. 
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3. IMPLEMENTATION DETAILS 

Problem Statement: 

There are two robots which we need to run asynchronously from a single JVM. We need to implement 
subsumption of the services by using different colors. There are two main services (wall follower and space 
wanderer) which can be run on any of the robots. These robots are equipped with sonar, position2d, and blob 
finder sensors. We want to implement this subsumption architecture on promise based asynchronous framework 
by measuring the processing time of services running asynchronously. We have an actor as a service provider 
for providing asynchronous services wall follower and space wanderer. Two robots (robot! and robot2) as 
an actor using or switching these services based on the color detection. An actor as an arbitrator is used to 
switch service from one robot to another, based on the color detection. 

The challenges in the implementation are: 

[1] How to ensure required sensor data is ready before invoking the service? 
[11] To define a rule to switch services from one robot to other based on the color detection. 
[111] Starting and stopping services running on different robots asynchronously based on color detected. 
[iv] How to update the color detected by a robot at the run time to the main code? 
[v] How to model a system which has N number of services running on N different robots detecting N number 
of different colors? 
[vi] How to verify that integrated components do not produce any deadlock? 
We have two robots: 
1. Robotl (id = 0, port 6665, color orange) 
Sensors 
i. Sonar sensor (distance with the obstacles) 
ii. Position2d (used to control the robot movements) 
11. Blob finder (used to detect the color obstacles in range) and 
2. Robot2 (id = 1, port 6665, color black) 
Sensors 
1. Sonar sensor 
lii. Position2d 
iii. Blob finder 

They are connected with PLAYER server for transmitting and receiving data on the network and 

the simulation environment is provided by STAGE. The details of the two services are: 


3.1. Wall follower service 

In this service, first, the connection is established with the robot. After connection, the sonar values 
are checked if they are ready or not. When sonar values are ready, these values are used to find the distance of 
the obstacles in front and left side. First, the robot is aligned to the left wall then the robot is made to follow 
the wall. The logic behind alignment with the wall and follow the wall is written separately. Both the codes are 
differentiated by a temporary (temp) variable. First, the robot left side is aligned with the wall (Table 1). When 
the robot left side is aligned with the wall, the value of the temporary (temp) variable is changed to O which 
causes second part of the code to run 1.e. follow the wall. The logic behind getting the wall aligned to its left 
side is that the robot will move forward until its left side sonar or front side sonar detects any obstacle. 

Max wall threshold = 0.4 cm 

Min wall threshold = 0.3 cm 

x: translational speed & 

y: angular speed (radian/sec) 

If none of these conditions is satisfied then our robot detected the wall to be followed and conditions 
in Table 2 are checked. This phase is known as following the wall present at left side. The temporary (temp) 
variable value is made 0 because there is no need to align the wall again to the left. 

These conditions in Table 2 help the robot to follow the wall. If the wall in the front is less than max 
wall threshold then the robot will turn right and if the left side wall is too near then also the robot will turn 
right. If the left side sonar value is more than max wall threshold then it will turn left. By default, the robot will 
move forward when no above condition is satisfied. There is a priority order in the above conditions. Upper 
conditions have more priority then below conditions. 
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Table 1. Logic for wall alignment to the left side of the robot 
Left sonar value Front sonar value Result 
<max wall threshold >max wall threshold Move forward (x=0.2, y=0) 


<previous left side <Left side Turn right (x=0, y= -0.45) 
<previous left side >left side Turn right (x=0, y= -0.15) 


Table 2. Logic for following the wall 


Left sonar value Front sonar value Result 
No condition <max wall threshold Turn right (x=0.1, y= -0.6) 
<min wall threshold No condition Turn right (x=0.1 , y= -0.15) 
>max wall threshold No condition Turn left (x= 0.1, y= 0.15) 


By default( no condition ) By default( no condition) Move forward (x=0.2, y=0) 


3.2. Space Wanderer and Color Finder 

In this service, first, the connection is established with the robot. After connection, the sonar values 
are checked if they are ready or not. When sonar values are ready, these values are used to find the distance of 
the obstacles in right and left side of the robot. In this service, a robot is made to travel in between 
the obstacles or wall and if the left sonar distance is less than right sonar distance then turn right with 
y = 0.5 radian/sec and x =0. To move in between the walls, x is set as ((left/10)+(right/10))/2 and y = ((left/10)- 
(right/10))*(180/pie)/wheel diameter. 

x is translational speed and y is rotational speed in radian. While the robot wanders, the color finding 
service is also running. This service uses blob finder sensors to detect the color. The logic for sending the color 
to the main code is different in callback and promise. 


3.3. Synchronous, Callback and Promise based implementation 

When subsumption occurs, or change in the running state, services switches to other services. The 
switching is fast so that robot does not colloid with the wall when no one is controlling the actions of the robot. 

The code shown in Figure 7 has used runThreaded a function of the player client. This function calls 
the start() function of thread class. Run function is called asynchronously. Run function in player client interact 
with the player server and gets the sensors values. This function updates the isDataReady function of player 
client about the sensors value. isDataReady function is used in the services for checking the sensors values are 
ready or not. When isDataRedy function replies truly then only we start the service. This is the solution to 
the first challenge discussed above. 


PlayerClient robot = null; 
Position2DInterface posil = null; 
Sonarintertace rngil = null; 
BlobfinderInterface blfil = null; 


try { 
// Connect to the Player server and request access to Position and Sonar 
robot = new PlayerClient ("Localhost", 6665); 
posil = robot.requestInterfacePosition2D (8, PlayerConstants.PLAYER OPEN MODE); 


rngil = robot. requestInterfaceSonar (0, PlayerConstants.PLAYER OPEN MODE); 

blfil = robot.requestInterfaceBlobfinder (8, PlayerConstants.PLAYER OPEN MODE); 
} catch (PlayerException e) { 

System.err.println ("robotl: > Error connecting to Player: "); 

System.err.printkn (" [ " + €.toString{) + " |"); 

System.exit (1); 


} 


robot.runThreaded (-1, -1);: 





Figure 7. Connection with robot sensors 
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Here we have used color as subsumption event. If a color detected other than orange (another robot 
color), black (walls) and the color of the state they are in, then the state of the model will change. On the basis 
of color detected by the robots, service is decided. We have two main services, the possible arrangement of 
services among two robots is 4 as shown in Table 3. 


Table 3. Possible arrangements of services 
Robot1 Robot2 


Wall Follower Space Wanderer 
Space Wanderer Wall Follower 
Space Wanderer Space Wanderer 

Wall Follower Wall Follower 


The state transition diagram of the services based on color detection is shown in Figure 8, which works 
on 3 states of the model. 







Robot 1 detects green 


Robot 1 detects red 


~ d 


Robot 2 detects green 
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Figure 8. State transition diagram of service switching 


In state 1, as shown in running demo of Figure 9, wall follower service in robot] and space wanderer 
with color finder service in robot 2, it is default services. This state occurs when robot senses blue color. Note, 
color finder service is only with space wanderer service. Only the robot running the space wanderer can detect 
the color and perform the subsumption of its own service with the other robot service. 

In state 2, as shown in running demo of Figure 10, space wanderer and color finder service runs in 
robot | and wall follower service runs in robot 2. This state occurs when robot senses red color. 

In state 3, as shown in running demo of Figure 11, both the robots runs with space wanderer and 
color finder service. This state occurs when robot senses green color. In this state, both the robots can detect 
the color and change the state of the model. 

The switching of the services can be depicted as in Figure 12, which works on the following rules 
which solves our second challenge discussed above are: 

[1] The default condition for statel is, lets assume this condition as A= _ robotl.color 
l= black & robotl.color != orange & robot1.color != state.color. 

[2] The robot changes its priority and goes to state2 based on condition, lets assume this condition as 
B= robot1.color = blue or robot2.color = blue. 

So priority of services are (robotl.service = SW  >robotl.service = WEF & 
robot2.service = SW <robot2.service = WF) if condition A and B are true. 
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[3] Again the robot changes it’s priority and goes to state2 based on condition, lets assume this condition as 
C = robot1.color = red or robot2.color = red. 

So priority of services are: (robotl.service = SW _ <robotl.service = WF & 
robot2.service = SW >robot2.service = WF) if condition A and C are true. 
[4] The robot changes it’s priority and goes to state3 based on condition, lets assume this condition as 
D = robotl.color = green or robot2.color = green. 

So priority of services are (robotl.service = SW  >robotl.service = WEF & 
robot2.service = SW >robot2.service = WF) if condition A and D are true. 

where State.color: color of the present state, WF: Wall follower service, SW: Space wanderer service, 
Robotl.color: color detected by robot! and Robot2.color: color detected by robot2. A Table 4 based on 
the above rule is presented below. 


Table 4. Conditions and outcome of different states 


Blue Color Red Color Green Color Robotl Robot2 State 
Yes No No Wall Follower Space Wanderer 1 
No Yes No Space Wanderer Wall Follower 2 
No No Yes Space Wanderer Space Wanderer 3 
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Figure 9. Running demo of two robots exchanging their services on color detection in state 1 
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The BIP [19] model of the implementation of the problem is presented below in Figure 13 for the two 
robots. We have used 3 different implementations of the same problem using: 


1) Subsumption using Synchronous mode. 
11) Subsumption using Asynchronous model of Actor & Actor with callback. 


111) Subsumption using Asynchronous model of Actor & Actor with Promise. 
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Figure 10. Running demo of two robots exchanging their services on color detection in state2 
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Figure 11. Running demo of two robots exchanging their services on color detection in state3 
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Figure 13. BIP model of two running robots switching their services 





3.4. Subsumption using Synchronous model 

Wall Follower service and Space Wanderer service functions are present in a single file. 
The connection with the robots is done only single time in the starting of the main code. Then in while loop, 
separation of colors are done for the states or subsumption. When the service starts in a state, 
the functions of service are repeatedly called till any different color is detected. This color should be different 
than the present color of the state, not equal to 0 (black) and orange (another robot color). When a color is 
detected, then subsumption occurs and state changes accordingly. Services are running one by one. For 
example, in state 1, robot] is running wall follower and robot2 is running space wanderer. 

In the Figure 14, the synchronous implementation is shown, when wall follower service completes its 
cycle then space wanderer cycle will start. At a single time, only single service is running and commanding the 
respective robot. The switching is fast (200-300 milliseconds) therefore we cannot differentiate with our eyes. 

We see both the robots are running their services. The total time taken is equal to a sum of the time 
taken by both the services. In the code, color! is for saving the color received by the space wanderer service 
and later used for checking the conditions for switching the states. Color4 variable temporary saves the value 
received by the service, before copying the color4 value in color1, color4 is checked for black color and orange 
color because these colors are not used in subsumption. 
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1f(colorl == 255) 

System.out.printin("State 1"); 

do{ 
wallF(posil, rngil, blfi1); ——————> WallFollower 
color4 = SW( posi, rngi, bfi); ———> Space Wanderer 


System.out.println(color4); 
1f(color4 !'=6 & color4 != 16753976){ 
colorl = color4; 





Figure 14. Code for services running synchronously 


We compared the time taken to complete 1000 loops of both the services in core2 and core3 machine, 
shown by graph presented in Figure 15. 
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Figure 15. Time taken in running services synchronously 


3.5. Subsumption using an Asynchronous model of Actor & Actor with callback 

Wall follower and Space Wanderer services are inside an actor and main code for calling the services 
are in another actor. Two reference variables of services class are made as actor. From the main code 
functions of services are called to run the services in the robot. Connection and control of the robot is defined in 
the services. There is a reconnection every time when the services are switched or subsumption occurs. 

In the Figure 16, the services are called asynchronously, it is difficult to stop the service from other 
thread. For stopping and starting a service, AtomicReference is used. The AtomicReference class provides 
an object reference variable which can be read and written atomically. By atomic meant that multiple threads 
attempting to change the some AtomicReference will not make the AtomicReference end up in an inconsistent 
state. Before starting the service in a robot, atomic reference of that service is set to 1. There is a loop in 
the service which checks the value of the atomic reference of the service. When we need to stop the service, we 
can set the value of the atomic reference 0 from the main code. For this purpose, we pass the atomic reference 
and id of the robot in the Wall follower service. This solves our third challenge of starting and stopping robot 
services. The id of the robot is used for connection with the robot. Space Wanderer has two services, therefore, 
two reference ids are passed for a robot id. To deal with the fourth challenge as above we have used a callback. 
For callback, callback as a function passed to the function. The color detected other than black is directly send 
to the main code where the color is checked. If the color defined for the running state is same as the color 
detected then no change in the state or subsumption. If the color detected is the orange i.e. color of another 
robot then it is also avoided. If a color other than these defined for different states detected than the change in 
the state or subsumption is done. It is faster than the synchronous model. 
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Figure 16. Messaging between space wanderer services with main code using callback 


The code presented for this model is given in Figure 17 below: 


System.out.println("State 1"); 
while(! (atomicRefSw2.get()==2)); 
atomicRefWFl.set(1); 


atomicRefsw2.set(1): 

atomicRefBF2.set(1); 

robot2.spaceWanderer((ch,err) -> { Space Wanderer 
color? = (int) ch; 
System.out.println(color2); 
Ssystem.out.println("received color "+System.currentTimeMillis()); 
1f(color2!=255 && color?!=16753926){ 
atomicRefwFl.set(®@): 
atomicRefsw2.set(@): 
atomicRefBF2.set(@); 
((Demo2?) self()).live(); 
} 


},1, atomicRefSw2,atomicRefBF?2); Wall Follower 
robotl.wallFollower(@, atomicRefwFl1); 





Figure 17. Code for Actor model using callback 


In this code, the color2 is used for saving the color received from the space wanderer service. Color2 
variable is used for switching the states by checking its value. When color is received and satisfy all 
the conditions, all the services are stopped by changing the values of atomic reference of respective services 
and then thread recalls the function live(). 

In the above case, we also compared the time taken to complete 1000 loops of both the services in 
core2 and core3 machine, shown by graph presented in Figure 18 below: 
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Figure 18. Time taken in running services asynchronously using callback 


3.6. Subsumption using Asynchronous model of Actor & Actor with Promise 

In the Figure 19, all the services are same as Actor with callback and use of atomic reference is also 
the same. The change is that the space wanderer is now had promise return type, which contains the color 
detected. The function called from main code provide atomic references, robot id, and the color of the present 
state as an argument. We use then function to use the color received after completion of the function. This 
color is used as a control point for subsumption by selecting suitable services. For subsumption, all the 3 states 
as discussed above, logic is written in a single function of the main code. The code presented for this model is 
given in Figure 20. 


synchronous cal 





Space Wanderer logic 
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color detection with the help ð 
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check for unique or different 
color 
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value of the color send back to the main code as promise 


Figure 19. Messaging between Space wanderer service with main code using promisek 


Int J Rob & Autom, Vol. 8, No. 4, December 2019 : 217 — 244 


Int J Rob & Autom ISSN: 2089-4856 g 231 


uf (color2==755){ 

System.out.printin("State 1"); 

atomicRefWFl.set(1); 

robotl.wallFollower(@, atomicRefWF1): Wall Follower 

atomicRefSw2.set(1); 

atomicRefBF2.set(1); 

robot2.spaceWanderer(1,atomicRefSw2,atomicRefBF2, 255).then(result-> { 
color? = result; 
System.out.printkn("color"+color2); 


Space Wanderer 


atomicRefSw?.set(@); 
atomicRefBF2.set(@); 
((Demo3) self()).Llivel);: 


}); 





Figure 20. Code for Actor model using promise 


By default value of color is blue. This causes state 1 run first. Any service, which needs to run on 
a robot, is set to 1 for its atomic reference and then call the respective function from the actor. In the space 
wanderer call, after receiving the color, wall follower service and space wanderer service is switched off by 
making their atomic references to 0. After this, the function calls itself. The function checks the color value 
and selects the state. This process repeats again and again. 


promise 





2 Cores 3 Cores 


BSpeceWandera Wall Follower 


Figure 21. Time taken in running services asynchronously using promise 


It is faster than synchronous and actor with callback. It sends a color only single time whereas 
a callback sends the color repeatedly till the service is switched off. 

In this code, color2 is set as 255 (color code for blue) in the parameter of the space wanderer service. 
Color2 variable is used for switching the states by checking its value asynchronously using then method. When 
the color2 is received other than blue, all the services are stopped by changing the values of atomic reference 
of respective services and then thread recalls the function live(). In the above case, we also compared the time 
taken to complete 1000 loops of both the services in core2 and core3 machine, shown by graph presented in 
the Figure 21 above which shows that services running on promise takes less time than callback. 


4. PERFORMANCE EVALUATION 

Space Wanderer service takes very less time than Wall Follower in covering 1000 loops of 
the service. Y axis: time in milliseconds & number of loops of service: 1000 & Cores = 3. 
Time difference between synchronous model, an actor with callback model and the actor with promise model. 
Y axis: time in milliseconds & number of loops of service: 1000 & Cores = 3. 
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The graph shown in Figure 22 shows that there is not much time difference between actor with callback 
model and actor with promise. The small time difference is because callback code needs to send the color back 
to main code repeatedly whereas in promise only one color is sent back to the main code in the end. To receive 
the color sent by the callback, the main function needs to synchronize with the callback function and process 
the data for subsumption. In the callback case, the main function stops the space wanderer service by atomic 
reference after processing the data received whereas in promise case, the space wanderer service close itself 
and send the color value as a promise to the main code. For time calculation, only the main logic part is used. 
Connection with the robot is not taken into consideration. 

In callback and promise, the while loop in the services are used in time calculation whereas in 
a synchronous model, both the function of the services are used for time calculation. The time taken by 
the callback function to send messages to the main function is almost equal to 1-2 milliseconds. In promise, 
the message is sent only once after closing the space wanderer service. 


Time taken by services 


350000 


300000 
250000 
200000 
150000 
100000 
50000 
o 


Callback Promise 


BSpaceWanderas Wall Follower 


Figure 22. Time taken in running services asynchronously using promise and callback 


The graph shown in Figure 23, depicts overall time taken by running services synchronously, 
asynchronous with callback and promise. The time taken in running services synchronously takes much time 
than the other because both the services run one after the other. 
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Figure 23. Time comparison graph in running services asynchronously 


Int J Rob & Autom, Vol. 8, No. 4, December 2019 : 217 — 244 


Int J Rob & Autom ISSN: 2089-4856 g 233 


5. VERIFICATION OF MODEL WITH THE HELP OF PETRI NET 

A Petri net (also known as a place/transition net or P/T net) is one of the several mathematical 
modeling languages for the description of distributed systems. A Petri net is a directed bipartite graph, in which 
the nodes represent transitions (i.e. events that may occur, represented by bars) and places 
(i.e. conditions, represented by circles). The directed arcs describe which places are pre- and/or 
postconditions for which transitions (signified by arrows). 

There are four primary components involved in the system: the robot, player server, middleware as 
promise based framework and services as shown in Figure 24. Service interact with middleware only. Other 
three interfaces of robot, player, and middleware interact with one another at some point during their respective 
lifetimes. 


Robot 





Figure 24. Component model of a Robot system 


The basic sequence of events or use case can be outlined as follows: 
[1] The robot is equipped with sensors. The robot takes the data of Laser Sensor/IR Sensor and put them in 
the proxies of the Player Server. Since the robot initiates the interaction, it is the requester and player component 
is the provider. 
[2] Player Server component sends the data to the middleware and then player server initiates, it becomes 
requestor and middleware become the provider. 
[3] The service component interacts with Middleware in order to register its services and to obtain the data. 
During the first phase, the role of the service component is requester and the middleware is provider. 
In the second phase, the role changes as the middleware initiate and sends the data to the services, it 
becomes requestor and service component becomes the provider. The reference of player sensors proxy is 
passed to the services. 
[4] Once the service component has all the permitted information than a decision is made to start the service. 
Here it chooses between wall-follower and wanderer services. 
[5] Finally Service is started and the Robot continuously sends the sensors data to the services component 
indirectly through player server and the middleware. This is continued till the robot wants to stop. 


5.1. Robot Interface: 

When the robot is started, it interacts with the player server and creates player proxies. Here Robot is 
requester and player is the provider. The values from the sensors present in the robot are now set in the proxies 
of player. Robot Interface is shown in Figure 25. 
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Figure 25. Robot interface 


5.2. Player Interface: 

Player provide proxies to the robot. The values are set on these proxies by the robot. These proxies 
are now transmitted to the middleware. Setting of the sensor data in the proxies and transmitting it to 
the middleware is continuously done till the robot is stopped. Player Interface is shown in Figure 26. 


provide proxies stop 


Trp 


set values in pro 


Figure 26. Player Server Interface 


5.3. Middleware Interface: 

Services are registered by the service in the middleware. After that, it receives the data from the player 
server. Middleware provides this data to the service and request to run the service. Receiving of data from 
the player server and providing it to the service interface continues till the robot is stopped. Middleware 
Interface is shown in Figure 27. 
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getting dats 


from player Service to run 


Figure 27. Middleware Interface 


5.4. Service Interface: 

Service register its services to the middleware. In this case, it registers wall follower service and 
wanderer service. Service receive the data from middleware and decide which service needed to run. 
This process continues till the robot is stopped. Service Interface is shown in Figure 28. 






register services 


Figure 28. Service Interface 


5.5. Composition 

The composition of requestor and provider net is done by the melding of requestor interface with 
provider interface. The resultant composition has 4 new place and 3 new transitions for each common 
single transition. The transition is removed and 2 new places added in the requestor. The other 2 
transitions added are synchronized with the provider. The place and transition added before the synchronous 
transition in the requestor are for removing the problem caused by the provider which changes the sequence 
of the requested operations. They allow the interaction with the provider and maintain the requestor sequence. 
In the composite net, the sequence of operations of the provider should not affect the sequence of requested 
operations. The other place of the requester is in between the synchronous transitions. 


Concurrent asynchronous robotic subsumption using actors & promises (Ratnesh Srivastav) 


236 g ISSN: 2089-4856 


5.5.1. Robot-Player Composition 

The composition of the robot request for the proxies from the player server composition is shown in 
Figure 29. R3”, R4’, P2”, P3” and Tr2”, Trp1”, Trp2” are new places and transitions respectively, added in 
the net for composition. Tr2” and R3” added in the robot (i.e. requestor) before synchronous transition (Trp1”). 
They allow the requestor to interact with the provider. The initial transition of the requestor is removed and 
two synchronous transitions (Trp1” and Trp2”) and 1 place (R4”) added. In the provider side, the initial 
transition (Tp1) remain unchanged between two new places P2” and P3”. They all together are in between 
the synchronous transitions Trp1” and Trp2’. These synchronous transitions are connected with the both player 
server (provider) and robot (requestor), places either sides (Trp1” input side and Trp?” output side). In this 
composition Figure 30, the robot set values in the proxies of the player server. Here robot is requestor because it 
initializes the interaction with the player server. Tr}, R7”, R8”, Trp3”, Trp4’, P5” and PO” are new transitions 
and places added in the robot and player server interface for composition. 
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Figure 29. Robot-Player Composition-I 
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Figure 30. Robot-Player Composition-II 
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5.5.2. Player Server-Middleware Composition 

In this composition shown in Figure 31, the player server sends the sensors data to the middleware. 
Here player server is requestor because it initializes the interaction with middleware. Tp3”, P8”, Tpm1”, 
Tpm2”, P9”, M5” and M6” are new transitions and places added in the player server and middleware interface 
for composition. 


M7 i 
Middleware 





Figure 31. Player Server-Middleware Composition 


5.5.3. Middleware-Service Composition 

In this composition shown in Figure 32, 33, middleware sends the data to the service. Service af- 
ter receiving data, it selects the service needed to run. Here middleware is requestor because it initializes 
the interaction with service. Tm2’, M8”, Tms3”, Tms4’, M9”, S5” and S6” are new transitions and places 
added in the middleware a service interface for composition. 

In this composition, Service registers its services in the middleware. Here service is requestor because 
it initializes the interaction with middleware. Ts1”, S2”, Tms1”, Tms2?”, M2”, and M3” are new transitions and 
places added in the middleware a service interface for composition. 


Middleware 





Figure 32. Middleware-Service Composition-I 
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Figure 33. Middleware-Service Composition-II 


5.5.4. Robot-Middleware-Service-Player Server Composition 

An overview of the net composition is outlined in Figure 34. After analyzing this Petri Net model, 
we got 44 minimal Siphons [20]. To detect the deadlock we need to minimize the no. of tokens in minimal 
siphons by using linear programming [21] with the help of constraints. 

These constraints correspond to places of the net and specify that the number of tokens in each place 
cannot be negative. After analyzing the model we found deadlock. The deadlock was arising because of 
stop transitions of these 4 interfaces were not synchronized. This caused irregular stopping and starting of 
the interfaces which resulted in a circular wait. When the token arises at P4 after player server providing 
the proxies to the robot, it has a choice to select between two paths that lead to the player server stop transaction 
and setting values in the proxies by the robot. All the transaction have the same priority, the player server 
can choose any path. Instead of waiting for the robot to get ready for interaction between them for setting 
the values in the proxies, player server triggers the stop transaction. This causes deadlock at the synchronized 
transactions Trp1” and Trp3”. Here circular wait problem arises. At Trp1”, the player server is waiting for 
the robot to accept the proxies and at Trp3” robot is waiting for the player server. Same kind of thing happens 
with middleware and service composition. This situation comes when Tms2” fired after the service registers its 
service in middleware. All the transactions have the same priority, service and middleware can take any path at 
this point. If service select the stop path and middleware select the Tpm1” path then there will be a deadlock 
at Tms1” and Tms3” in future. A circular wait problem arises here. Middleware is waiting for services to 
accept the sensors data and service are waiting for middleware to register the services. This caused deadlock in 
the system. This is also verified by using State Space analysis module of PIPE(Platform Independent Petri net 
Editor) tool shown in the Figure-35. 

Changing the priority of the transaction, stop transaction with lower priorities than the normal 
transaction so that stop transaction will fire at last, does not help. It removes the deadlock but the robot never 
stops. The stop transactions have the least priority, they never fired and the process of sending sensor data to 
the services never end. To overcome this problem, we synchronized the stop transitions of other interfaces with 
the robot stop transition. When the robot wants to stop, it fires its stop transition (Tr6) and token reaches at R10 
place, see in Figure 36, 37. 

The next transition is synchronized stop of other three interfaces. When the token reaches R10, 
now it becomes necessary for other interfaces to stop because there no other path to select. After firing 
the synchronized stop, the robot model comes to its initial state or starting state. Synchronize stop remove 
the circular wait and irregular stopping and starting of the interfaces. 
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Figure 35. State Space Analysis 
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Figure 37. Middleware-Service Composition part of Figure 38 


Now the player server provides proxies to robot and service register its services in middleware one 
time only when the model runs from starting. This removes the unnecessary repetition of transactions which 
was happening in the previous model. Now the player server, middleware, and services will stop only when 
the robot wants to stop. The new Petri net model is shown in the Figure 38. Where yellow path shows 
the continuous working of the robot, red path shows Stop and blue path shows back to starting position. 
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Figure 38. Corrected Robot-Middleware-Service-Player Server Composition 


In the new net, we tried to minimize the tokens in siphons with the help of constraints. At last, we 
didn’t find any siphon with 0 tokens. We also did the reachability analysis on the net where we did not find any 
dead place. So, we can say that the model is deadlock free. This is also verified by using State Space analysis 
module of PIPE(Platform Independent Petri net Editor) tool shown in the Figure 39. 
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Figure 39. State Space Analysis of new net 
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6. CONCLUSION 


We conclude that in synchronous and asynchronous communication promise are better than using 
a callback. We have compared the time taken in completion of services and found that services running using 
promise take less time as compared to callback and synchronous. Petri nets used for verification of concurrent 
robotic system integration helps us to find out the issues of deadlock using siphons prior to building the system 
for integration. Systems composed using Petri nets adds extra transition and places to compose common 
transition between requestor and provider. Our promise based framework provides the facility of using already 
available robotic components as an actor which can communicate with another the actor asynchronously using 
a single threaded model as supported by Node.js [22]. In future, we aim to verify the architecture of our 
integration system by checking the coordination control constraints in different Petri net composition model as 
proposed in paper [23]. 
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